Record the answer to #319 on the slot it is about: hosts are not members - #501
Merged
Conversation
#319 asks whether hosts and antagonists should be `taxonomy` members. The answer is no, and it is recorded on `taxonomy` rather than left in an issue thread. **No data changes.** "No" is the status quo - those 11 participants are already outside `taxonomy` and stay there. What changes is that the reasoning stops being re-derived: the question was worked out at least twice from the same evidence, once when the auditor was written and once when tests/test_interaction_participants_outside_taxonomy.py was, and each time the conclusion went into a comment rather than into the slot everyone reads. The decision, with the scoping that makes it easy: * of the 25 interaction participants outside `taxonomy`, **14 are UMBRELLA names for members that ARE present** - `Variovorax` where the record lists `Variovorax sp. CF313`, `YR634` and the rest. Those are a naming coarseness, not a membership question, and nobody would duplicate them into `taxonomy`. * the real question is the remaining 11: **6 hosts, 3 antagonists, 2 abiotic**. A community lives ON its host and is applied AGAINST its antagonist; neither is what the community is made of. `taxonomy` already said "organisms present in the community", so this sharpens existing wording rather than changing the model. Consistent with #307, which answered the mirror-image question the same way and for the same reason: candidates screened OUT are also not members, and live in `engineering_design.counter_selection`. An edge to something outside the community is not evidence that it should be inside it. The auditor's existing treatment is already right under this answer - those participants are reported at warning severity rather than gating (#326), which is what you want for a deliberate absence. Mutation-checked: reverting the slot description to its one-line form fails the new test. Still open in #319's territory, and NOT decided here: the fragility that the shielding rests on a single optional key. `scope` has `ifabsent: string(PAIRWISE)`, so dropping it from one interaction turns that participant into an error. That is pinned by `test_all_of_them_are_warnings_not_errors` and worth its own fix. validate-strict 0 errors, 2371 passed, docs regenerated.
Network integrity findingsWarnings only — a member with no interaction yet, or a participant matched by ontology id rather than by name, or one on a community-level interaction that resolves to no member. Reported, but does not fail the build. The full report is attached to the workflow run as an artifact. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #319.
No data changes. "No" is the status quo — those participants are already outside
taxonomyand stay there. What changes is that the reasoning stops being re-derived.Why record it at all
The question was worked out at least twice from the same evidence — once when the network auditor was written (#326, which downgraded these to warning severity citing #319 by name) and once when
test_interaction_participants_outside_taxonomy.pywas. Each time the conclusion went into a comment rather than into the slot everyone reads.taxonomyalready said "organisms present in the community"; this makes the implication explicit.The scoping that makes the decision easy
Of the 25 interaction participants outside
taxonomy:Variovoraxwhere the record listsVariovorax sp. CF313,YR634,GV004…;Olsenella (Actinobacteriota)where taxonomy hasOlsenella_B sp. (MAG ATO3). A naming coarseness, not a membership question. Nobody would duplicate those.A community lives on its host and is applied against its antagonist. Neither is what the community is made of.
Consistent with #307
That issue asked the mirror-image question — do deliberately screened-out candidates belong in
taxonomy? — and answered no, for the same reason. They live inengineering_design.counter_selectioninstead. An edge to something outside the community is not evidence that it should be inside it.The auditor's existing behaviour is already correct under this answer: these are reported at warning severity rather than gating, which is what you want for a deliberate absence.
Verification
Mutation-checked: reverting the slot description to its one-line form fails the new test. Asserted positively — the description must say hosts and antagonists are not members, so a rewrite that silently drops the reasoning fails rather than passing.
validate-strict0 errors,2371 passed, docs regenerated.Not decided here
The fragility #319 also names: the shielding rests on a single optional key.
scopehasifabsent: string(PAIRWISE), so dropping it from one interaction turns that participant into an error and reddens the build on a record nobody changed the biology of. That is pinned bytest_all_of_them_are_warnings_not_errorsand deserves its own fix — a participant's absence fromtaxonomyshould probably be shielded by something that says why it is absent, not by an unrelated key.🤖 Generated with Claude Code